Machine type communication is a form of data communication that involves one or more entities that do not necessarily need human interaction. A service optimized for machine type communication differs from a service optimized for human-to-human (H2H) communication. Typically, machine type communication services are different to current mobile network communication services as they involve different market scenarios, pure data communication, lower cost and effort, and a potentially very large number of communicating terminals with little traffic per terminal.
The terms Machine-to-Machine (M2M) and Machine-Type Communications (MTC) are used to describe use cases and illustrate the diverse characteristics of machine type communication services. M2M and MTC devices will be part of the next generation wireless networks to enable “internet of things”. Potential M2M and MTC applications include security, tracking and tracing, payment, health, remote maintenance/control, metering, and consumer devices. The main characteristics of machine type communication services include low mobility, time controlled, delay tolerant, packet-switched only, small data transmissions, mobile originated only, infrequent mobile terminated, MTC monitoring, priority alarm, secure connection, location specific trigger, network provided destination for uplink data, infrequency transmission, and group based MTC features.
The end-to-end application between an MTC device and an MTC server or between two MTC devices is provided by 3GPP systems. A 3GPP mobile network provides transport and communication services optimized for MTC. However, the number of M2M devices in the mobile network is expected to be much larger than the current number of UEs, i.e., an order larger. With such vast number, the network could run out paging resources and incur extra delay. For example, with maxPageRec=16 and the maximum paging subframe is four for a radio frame, the mobile network could page 6,400 MTC devices in a second at most. Thus, a potential problem is that the current paging resource will not be enough for future MTC devices.
Currently, there are a few solutions for page overload in a 3GPP mobile network. One solution is to prioritize paging on the S1 application protocol (S1AP) to selectively discard pages at temporary overload. Another solution is to change paging configuration dynamically by system information block (SIB) modification. Both solutions, however, may not work well for MTC devices. This is because, for certain M2M applications, it may have very low duty cycle due to power saving concern. For example, an MTC device only wakes up when it has uplink (UL) data or has much longer Discontinuous reception (DRX) in idle mode than currently allowed. In addition to DRX in idle mode, an MTC device may even have longer sleep cycle if the DRX value is not long enough for its operation. When paging occurrence (PO) happens, an MTC device does the following: wakes up before PO and checks system information (SI) value tag and obtains the latest SIBs; monitors Physical downlink control channel (PDCCH) for Paging-Radio Network Temporary Identifier (P-RNTI) for several DRX cycles; responds if there is a matching ID; and goes back to sleep when time is up.
If paging overload happens, it takes several seconds for eNB to reconfigure the paging channel. After reconfiguration, it takes more time to digest the congestion. Therefore, it is possible that eNB would not be able to page an MTC device in time before it goes back to sleep. Then the delay would be minutes or even hours. Furthermore, if eNB decides to reconfigure paging configuration after the overload is resolved, then a normal UE has to acquire the SIBs TWICE for no benefit. Thus, such paging overload event would degrade performance for normal UEs in idle mode.